The only memory that RamDos actually needs exclusively is the relocatable interface page (256 bytes) the DMA code at around $3f0, and a few of the vectors in page 3. Ramdos actually lives in the REU and swaps itself into memory as needed so any code that was in memory is safe in the REU when Ramdos is executing, and is swapped back when Ramdos is done. A 8K block of memory from ($2000 to $3fff on the 128 and $6000 to $7fff on the 64) is swapped each access. You can test this out by filling that area of memory with the fill command of the monitor and then using Ramdos, when you return the filled memory will still be intact.
---------------------------------
Ramlink/Xpnded REU?
From: George Page
Huh? "Anyone with a Ramlink has no need to expand an REU".?? Then why did I run one of mine up to 2meg, and others have also done it. Zed (unless I've totally lost my mind, which is likely), takes full advantage of the expanded REU as buffer space, not the RAMlink. Dialogue, for instance, can save a buffer capture slightly larger than ZED can handle with an unexpanded (512K) REU. So to work with a full 512K Dialogue buffer dump, within Zed, the expanded REU is needed. Just my 2 coins worth. :)
-------------------------
8 meg reu??
From : Steve Craik
To : Ed Paulsen
EP> SC> Actually, if I recall, Andrew Mileski (Recursion, on QLink now defunct) ..back when he provided a new RAM-DOS version that would SNIFF out larger REU's.. is where I first heard of this 8 meg reu topic. It was either in the FILE DESCRIPTION on QLink or actually in the DOCs for the RAM-DOS version (sorry, forgot which version number that is, I know I got it though.. and prolly will check the doc from it)
It's "RAMDOS ][" or RAMDOS][.SDA
I checked the DOC file and it says it'll sniff out up to 8megs. It didn't say anything about an actual REU that had it. I thought, I had buffered all the QLINK file description.. and REPLIES. I used to do that so as to quickly realize what the file was for. So on my disk would be: (something like this, if I did)
RAMDOS2.DESC ;Qlink decription & replies
RAMDOS2.SDA ;the file itself
Trouble is.. I saw the RAMDOS*.SDA but not the *.DESC. It could be that its on a 1541 disk.. I'd originally didn't have that QDOS thing that would allow you the option of redirecting downloads to a 1581 disk. Maybe thats what happened.. then I only backed up the *.SDA file though that seems strange.. I usually include both, as "S.O.P.".
You are right though, it seems rather frivolous to upgrade a REU when we have other alternatives.. CMD HD's and RAMLink. At least frivolous, beyond 2 megs. I do see some advantages, in having an expanded REU. Especially if you do have RAMLink and the battery backup and *DON'T* have a fully populated RAMLink. Once RAMLink is at its MAX 16megs ..it doesn't seem worthwhile to configure in the REU and loose whatever your REU size in Kbytes is.. of RL-Ram for REU Ram. I think it would we'd be better served switching the REU placement into the PASS-THRU port. By the switching you could have complete usage of all the 16 meg of RL-Ram ..PLUS.. upto 2megs of REU Ram. All pending just which way you toggle your DIRECT/NORMAL switch. ..anyway 18 megs of total ram is alot more than just 16 megs. <grin>
EP> SC> Then again.. I only have 1.5 megs in my REU so maybe I'm not at that threshold.
EP> Well, put some more in and report back!! (g)
I've thought about it. For GEOS it would be NICE to have my REU configured so that the REU was a 1581. Right now, the way I have things occupying my battery-backed REU:
usage. It installs itself in the very last REU bank.
(must use "setram" from Bruce Vrieling's CSEXTR45.LZH)
2) 512Kbytes ACE usage - REU ram or INDIRECT-REU
config.edited first reu bank 8, last reu bank 16
1) 512Kbytes Geos, and other Prgs that use bank 0 thru bank 7
mild drawback.. CS-DOS pokes for utility usage:
poke 7119 (firstbank)*16+(lastbank) ;LHA
poke 7120 " " " ;CSARC1750 & TERM
The pokes can ONLY be entered in for the first 512k.
its an inadequacy of BASIC (I guess). It would be
NICE if they could be poked higher thus lessening the
chances of OVERWRITING banks when quiting one program
and going into another. For pacticallity I make the
buffer areas the last few banks.
poke 7119 6*16+8 ;uses reubanks 6,7 aka 128kbytes
Then so long as my GEOS ram1571 doesn't use more than
384kbytes, those buffer areas aren't written to NOR
vis-a-vis ..since poked higher.. do the buffers
overwrite the data contained in the lower banks
anyway.. with the extra 512k then..
4th 512k CS-DOS
3rd 512k ACE
2nd 512k Geos r1581 uses 1meg
1st 512k " "
Notice how I sorta pictorally represent the piggy-backed DRAM chip layers.. neat huh? <grin>
Doubt that I'll do it though, its a BIG drag to backup the entire REU to re-do RAMLink's setup just to add the extra 512k. Besides, since I used sockets on the REU's printed circuit board.. the DRAM chips would need MORE room necessitating either the sockets removal or the cutting of the plastic REU housing. GOSH.. think of it.. if a similar process is used for expansion to 8 megs. That'd be quite a STACK of piggy-backed chips. It prolly would be a problem if you inserted the REU in RAMLinks pass-thru port.. ..there prolly wouldn't be room to insert something in the RAM-Port. MORE headaches than its worth!
------------------
ROM 17XX REU, 128
From: paul.fisher@bbs.wline.se
I've played around with the empty socket in the REU's a little, it's easy to put in a 27512 in there and have a whole 64K insted of 16 there's a jumper that selects the size of eprom and then a switch on the highest pin of the 27512 fixes it to emulate 2 seperate 32K eproms (27256) My weakness has been the ability to code rutins to move things around in memory and the such. So I just went into the builtin machine code monitor and Transfered memory from the eprom to basic RAM and presto it was loaded. More elaborate things can be done and you can use it in 64 mode also with a little modifications.
